1. Field of the Invention
This invention pertains to an apparatus for analyzing and systemizing current software assets, such as programs and job control data, for a computer system. More particularly, it relates to an apparatus for providing discriminant criteria of software assets and for providing data showing the asset characteristics and their interrelation as a reference for efficiently systemizing the assets.
2. Description of the Related Art
Recently, computer systems form critical backbones in executing corporate strategies, and the corporate software for its business application ever increases in volume and play vital roles. However, the current larger-scale and more complicated software assets are not well maintained under current management method, and the affairs related to controlling the software assets need to be managed more efficiently and properly. It is an urgent requirement to provide an integrated maintenance environment, which is easy and comfortable to use, by grasping the status of current software assets on a up to date basis and systemizing them in a well maintained manner.
Software inventories of computer systems include job assets such as JCL (job control language), program assets such as those written in COBOL (common business oriented language), DB/DC environment definers such as ADL (a language for defining the operating environment information for AIM as an integrated online database) and ACS (a software tool for assisting the development of AIM application programs), and screen/form definers such as PSAM (an asset for defining/creating the screen and form formats).
When a system analyst and/or application designer systemizes various software assets such as programs and job control data, he has to acquire enough information on the exact languages in which those assets are written and their interrelations, duplication or deficient of assets so that he can appropriately perform his task without any delay. Therefore, it is imperative to know exactly which asset types are there in the first place.
In so doing, by reading the contents of the software assets to be systemized through a printout or a display, the programming language is determined by a unique character string. Also, by decoding the output according to specifications of the programming languages, the asset names and the asset types need to be identified.
Also, by detecting e.g. caller of subroutines, procedures, copies and schemers, the asset interrelations (parent/child relations) amongst the software inventories are determined. The data thus obtained are sorted in a table format to be used at a glance as software asset systemizing information.
FIG. 1 is a flowchart for explaining the prior art method of confirming the existence or nonexistence of a software asset.
[START] When the process starts, step S1 is invoked.
Step S1: The content of a designated software asset is analyzed. Then, step S2 is invoked.
Step S2: An interrelated asset is detected. Then, step S3 is invoked.
Step S3: The existence or nonexistence of the interrelated asset is examined by searching a library and its information is outputted. Then, the process ends. [END]
FIG. 2 shows a prior art example of confirming the existence or nonexistence of a software asset.
A software group 4 comprises program assets 5, 6 and 7. By applying the method illustrated in FIG. 1 to program asset 5 (having an asset name A), it is confirmed that program asset 6 is interrelated.
By applying the method illustrated in FIG. 1 to program asset 6 (having an asset name B), it is detected that interrelated asset C exists and that interrelated asset D does not exist. By applying the method illustrated in FIG. 1 to program asset 7 (having an asset name C), it is detected that interrelated asset D is deficient.
However, the prior art method illustrated in FIG. 1 has a disadvantage of taking too much time for systemizing assets. This is because the interrelated software assets are searched only as necessary and not in a systematic form. This in turn invites the possibility of searching for the same asset a number of times. For instance, FIG. 2 shows that the process for software asset 6 is for searching interrelated asset D and that the process for program asset 7 also is for searching interrelated asset D.
Creation of systemizing information relies heavily on human interactions which takes many steps as described above. Therefore, as the system becomes larger and more complicated, it not only takes much time and money but also tends to produce omissions of and misjudgments in those analyzing process.
However, attempts to automate the systemization have invariably failed, because there has been no suitable automating technique for precisely analyzing various asset types, descriptive language types, asset characteristics, deficient assets, duplicated assets, and identical assets, or for organizing the information obtained by analyzing interrelated assets. This has in turn hindered analyses and systemization of software assets.